When debugging System on a Chip (SoC) it is often desirable to use non-invasive debugging techniques which allow the capture of information in real-time without altering the device undergoing testing. This information is often referred to as trace information. Trace information can include instruction and data information from a processor, on-chip bus transaction information, and other signals in the SoC. The trace information can be captured either off-chip by a trace port analyzer (TPA) through a trace port or can be captured on-chip in an embedded trace buffer (ETB). Debugger software analyzes this trace information and puts it in a form that allows the user to determine what is going on inside the SoC allowing for debugging of the SoC (hardware and firmware) and for optimization of firmware.
When designing a SoC, considerations must be made as to the hardware required for capturing trace information. These considerations include determining the width of the trace port for off-chip capture, determining the size of memory for on-chip trace capture, and determining the appropriate speeds of clocks in the debug and trace system.
CoreSight Architecture from ARM, Ltd. provides hardware for generating trace source information (Embedded Trace Macrocell (ETM), AMBA (Advanced Microprocessor Bus Architecture) AHB (AMBA High-performance Bus) Trace Macrocell (HTM)), for merging and transferring this information throughout the SoC (AMBA Trace Bus (ATB), funnel block, replicator block), for capturing the trace information on-chip (Embedded Trace Buffer (ETB)), and for driving the trace information off-chip on the trace port for off-chip capture (Trace Port Interface Unit (TPIU)). When designing a SoC using the CoreSight Architecture, ARM Ltd., recommends simulating the firmware with the architecture to ensure the design will meet trace bandwidth needs. For example, to determine whether the trace port width, size of ETB SRAM, and clock speeds are adequate. ARM does not provide a quick estimation tool.
In order to select the proper SoC technology, the clock speed, gate-count and power information must be determined. The on-chip buffer size must be determined in order to estimate the die size. The IO pin count must be known to determine the package. This information is needed early for estimating the price of the design, for designing the system board, for selecting the correct architecture necessary to implement; to meet time-to-market goals, and to allow implementation of a successful trace system.
An early method to evaluate the SoC design and to make trade-offs in an architecture is to use ESL methods such as System C or SystemVerilog simulations. ESL methods require models for all blocks in the design as well as representative firmware to run. However, sometimes the blocks and firmware are not available to perform ESL simulations early in the design flow.
Another method for evaluating the SoC design is to run simulations with the firmware with either high-level modes, RTL or gate-level netlist in order to finalize clock speeds, RAM sizes, and IO pins (trace port) requirements. Running the simulations requires that firmware has been developed and is available for the SoC. It also requires some representation (high-level models, RTL or gate-level netlist) of the design. Sometimes one or both of these items are not available at the time of initial design work. Waiting until the firmware is completed and the RTL or gate-level netlist are available, however, is not practical.
Another method for evaluating the SoC design is to estimate/guess (hopefully based on previous design experience). Estimations will need to be made as to the clock speeds, SRAM size, and trace port width. If the estimate is not accurate, however, many factors in the design process will be affected. If the estimate is grossly inaccurate, serious delays in the chip development could cause a delay and market window for the chip to be missed, or could result in a debug trace system which does not work. If a prototype debug is used, it could also result in troubles using the debug trace system to debug the design and/or firmware leading to time to market issues.
Finally the SoC design can by evaluated using hand calculations. Performing hand calculations, however, can be tedious and error prone.
The present invention provides a software program and method which overcomes the problems presented in the prior art and which provides additional advantages over the prior art, such advantages will become clear upon a reading of the attached specification in combination with a study of the drawings.